prw_powerrangersfandomcom-20200214-history
Template talk:Navbar
Add optional "namespace" param In an effort to improve , I have added an optional "namespace" parameter in and added a test case in . I would like to know if this is acceptable before I implement it in the actual template. עוד מישהו Od Mishehu 16:22, 26 October 2008 (UTC) :I can see no fault in the code, but what is the motivation behind this change? — Edokter • Talk • 16:38, 26 October 2008 (UTC) ::The code should normalize the namespace using . It's called T'navbar since its for templates, we have for User space templates and probably should create for Wikipedia space templates. Other than that I can't see any other namespace that could using this template. Also should be userfied. — Dispenser 18:05, 26 October 2008 (UTC) :::The motivation behind this is so that I can perform a similar change to where it uses this template, and then we will be able to delete pages which start with Template:User: - by making it . עוד מישהו Od Mishehu 08:00, 27 October 2008 (UTC) ::::I had constructed a simpler template that didn't include the bloat of features of this template at . I also had purposed that navbar= parameter could be used to specify code so other template could be used. But nothing's come of it for some reason. — Dispenser 15:43, 28 October 2008 (UTC) v • d • e (again) I find it very perplexing that the expanded version shows view • '''t'alk • edit and that the other one shows v • '''d • e. The fact that talk and d''' are the same thing just doesn't make sense; please change '''d to t'''. Chris 13:59, 15 November 2008 (UTC) :The '''d stands for "discuss", which makes a better abbreviation then t'. — Edokter • Talk • 15:22, 15 November 2008 (UTC) ::I know that, I just think that it would be better if the same letter were used for both versions of the template. Chris 15:59, 15 November 2008 (UTC) :::I agree with ChrisDHDR. The short form should be the same as the long form, so either "view • discuss • edit" and "v • d • e", or "view • talk • edit" and "v • t • e". :::The middle link is to a "talk page", we rarely call them "discussion pages". And I find the longer form "view • discuss • edit" too long. So "view • talk • edit" is better. Thus I think the short form should be "v • t • e". :::--David Göthberg (talk) 00:17, 17 November 2008 (UTC) ::::I think the original reason was that "t" rendered too small to click on (only 2 pixels wide). In any case, this change has a relatively big impact, so it needs broad consensus. I feel this is better discussed at the Village Pump. — Edokter • Talk • 00:51, 17 November 2008 (UTC) :Well, I made a screen dumps of the examples on this template's doc page, and checked in my image editor: In all three of my browsers the "v" is 5px wide, the "d" and "e" are 4px wide, and the "t" is 3px wide. So yeah, the "t" is a bit thin, but I still think we should use a "t" since the "d" is confusing. :--David Göthberg (talk) 07:49, 17 November 2008 (UTC) * Here the tab at the very top of the page is labeled "discussion", whereas the page is named "Template ''talk...", so it looks like the mixed description extends into the wiki software itself. Perhaps if/when there's consensus to choose one or the other description there it can be applied here too. Sardanaphalus (talk) 09:08, 22 November 2008 (UTC) Show/hide link width reduced The show/hide link generated by the collapsible tables code in MediaWiki:Common.js has been reduced from 6em to 3em in width. As a result, the title bars in navboxes are offset to the right, caused by this template. I'm not 100% sure what changes need to be made, though, which is why I didn't put an editprotected request here too. I'm also not really clear how the caching comes into play or how to circumvent it until it expires. Any comments? —Dinoguy 21:43, 17 November 2008 (UTC) :I've reverted the change in common.js for now. I agree that tnavbar and show/hide could take less space, but we need to find out by how much. The change was made too impulsive, as 3em is too narrow for tnavbar. — Edokter • Talk • 22:44, 17 November 2008 (UTC) noedit parameter It makes no sense to have an edit link for fully-protected templates. I propose adding a noedit=1 parameter for added customization. Proposed code is in the sandbox and testcases are available here. Thoughts? --MZMcBride (talk) 18:53, 21 November 2008 (UTC) :Done. --MZMcBride (talk) 23:36, 22 November 2008 (UTC) :* Thanks! Sardanaphalus (talk) 10:06, 23 November 2008 (UTC) Bracket option request As mentioned before /Archive 1/#Design improvements. Please consider adding brackets that looks exactly like the collapsible show/hide button so to distinguish between header text in slender template. The brackets can not be added manually because there're 1 space around the v-d-e by default (even with nodiv=1,) and header porperty will end up bolding the brackets so it looks abruptly. Thx -- Sameboat - 同舟 (talk) 14:17, 20 January 2009 (UTC) :Added the brackets=1 option to the sandbox. See the testcases page. — Edokter • Talk • 23:50, 4 March 2009 (UTC) :: Quite satisfying :) User:Sameboat/x3 -- Sameboat - 同舟 (talk) 00:59, 5 March 2009 (UTC) New version is ready The next version of this template is technically ready to go live. New 'features' include the implemetation of the noedit=1 and brackets=1 option, which should be self-explainatory. noedit hides the edit link (usefull for permanently protected templates) and brackets will show brackets around the links. See the testcases page for how that looks. But before deploying, there is one thing that I want input on. I'd like to hear what you think about the font size. The current sandbox version has a slightly larger font, as can be seen in testcases. This would not be apprearent in navboxes, as that reduces the fontsize again. Would you prefer the larger size, or prefer the current size? Opinions welcome. — Edokter • Talk • 21:56, 5 March 2009 (UTC) :I've got a question, but it's related to the testcases page as opposed to the proposed update - why are the live and sandbox versions shown in two separate sections? That just makes comparing their output that much more difficult. Why not show them side-by-side, as is done with, for example, Template:Nihongo/testcases? 「ダイノガイ ？！」(Dinoguy1000) 22:06, 5 March 2009 (UTC) ::WP:SOFIXIT :) The testcases page isn't protected. I'll do it when I get home. — Edokter • Talk • 23:30, 5 March 2009 (UTC) :::Yeah, I thought so, just wanted to make sure there wasn't some reason for it I wasn't aware of. =) --Dinoguy1000 as (talk) 00:39, 6 March 2009 (UTC) ::::All done. — Edokter • Talk • 00:52, 6 March 2009 (UTC) :::::Yep, I editconflicted with you (then ecided to discard my edit and tweak your version). =) --Dinoguy1000 as (talk) 01:09, 6 March 2009 (UTC) :Would there be any objection to adding a history link, enabled via }, }, or similar? --Dinoguy1000 as (talk) 01:09, 6 March 2009 (UTC) ::The history link idea is a bit strange to me. But I see no harm to have this as an optioanl entry. -- Sameboat - 同舟 (talk) 01:57, 6 March 2009 (UTC) :::Personally, I think we should stick with the three main links. Other templates (ie. ) do have more link options. Tnavbar should stay 'minimal' because it is used in over 600.000 pages. — Edokter • Talk • 02:20, 6 March 2009 (UTC) ::::That's fine, just wondering about it. =) 「ダイノガイ ？！」(Dinoguy1000) 18:00, 6 March 2009 (UTC) Edokter, why the insistence that "the talk page link should always be blue"?? Every other link on Wikipedia uses colour to distinguish between an extant and a nonexistent page; why should these links be any different? And using a hardcoded style certainly doesn't work: have you looked at it in CologneBlue or Simple? Why should we make such an effort, and actually make it look worse than before, simply to hide metadata that could actually be valuable? [[User:Happy-melon|'''Happy]]‑[[User talk:Happy-melon|'melon']] 11:33, 7 March 2009 (UTC) :Check the archives of this talk page, and those on navbox too; consensus was to not draw attention to a non-existent talk page, so the link should stay blue. — Edokter • Talk • 14:51, 7 March 2009 (UTC) ::It's a monobook-centric viewpoint to equate "existing" and "blue". I can't see any extensive discussion (although I admit I haven't read all the navbox archives) only NedScott getting almost no reaction back in 2006. Unlike recolouring the whole text, which is an obvious and transparent abandonment of the redlink/bluelink standard, pretending that a nonexistent page does in fact exist is pure deception. If we don't want to draw attention to it, we should use an #ifexist: and only link to it if it exists. [[User:Happy-melon|'Happy']]‑[[User talk:Happy-melon|'melon']] 18:52, 9 March 2009 (UTC) ::: #ifexist: is a very expensive hit which does impact performance in a way we do have to worry about; it would execute everytime a page containing Tnavbar is edited. As I recall, it causes a recursive database lookup, which is one of the reasons why the preprocessor statement limit was decreased from 100.000 to 2000 not too long ago, because #ifexist: was clogging the preprocessor. This is simply not an option. :::Besides, while I agree in general that non-existent pages should be visible in normal links to article- and Wikipedia space, it is not that important for templates I beleive. And, when fontstyle is used, the distinction is gone as well. I also know it's monobook-specific, but it is the most used skin, and the default link color is not too far off from other skins' link color. — Edokter • Talk • 23:31, 9 March 2009 (UTC) ::::I'm fully aware of the nature of #ifexist:, that's why I put the link in. The database lookup is not recursive; it's the same level of server load as the function, a single-row lookup from the page table. It's certainly used far more gratuitously and liberally in other, equally-popular, templates. Five hundred thousand extra lookups is not going to bring down the 8th most active website, and even if it does, a dev will trout us for it and we'll go on as before. If a dev removes the function, obviously that's a whole different ballgame, but they haven't, and they haven't set any technical restrictions to prevent us using it, so we should use it if it is appropriate, as it is here (certainly more so than pretending that red is blue). [[User:Happy-melon|'Happy']]‑[[User talk:Happy-melon|'melon']] 08:58, 10 March 2009 (UTC) :I've advocated spliting the template into two. One ultra-minimal design for use with those tens of thousands of navboxes and this one packed with features that are rarely used. This would be a good balance between features and performance, with the upside that we could readily add features here without worrying much. — Dispenser 04:11, 10 March 2009 (UTC) ::The new template removes the and parameters (we will indicate in the doc that users should use and as replacements) which are unused, and the param. The template has got a lot simpler, not more complicated, fortunately. [[User:Happy-melon|'Happy']]‑[[User talk:Happy-melon|'melon']] 08:58, 10 March 2009 (UTC) Ok, I've deployed the new code, without the blue override for the 'd' link. If we get howls of protest then of course we'll need to user #ifexist:, replace the colour, or do something more clever; but let's see if there's actually an issue here before getting worked up over it. [[User:Happy-melon|'Happy']]‑[[User talk:Happy-melon|'melon']] 17:26, 14 March 2009 (UTC) :I got here from noticing a difference, is it possible that the v e d to become that bit smaller again? I think it looked better before. chandl · 17:59, 14 March 2009 (UTC) ::I agree; I've changed it back to the old xx-small. [[User:Happy-melon|'Happy']]‑[[User talk:Happy-melon|'melon']] 20:10, 14 March 2009 (UTC) :::Great. And on the "red link for d" disscussed above, just initial thoughts were "hmm that isn't how it used to look?", even though I can see both sides pro's and con's, that it might be bad to give the impression that the talk page exist, and at the same time a bit distracting and quite noticeable when you see the classing red link, I think everyone will get used to it in the long run. chandl · 20:31, 14 March 2009 (UTC) ::::What do you think about it being an unlinked black 'v' if the page didn't exist? [[User:Happy-melon|'Happy']]‑[[User talk:Happy-melon|'melon']] 20:38, 14 March 2009 (UTC) :::::Should probably be fine I guess, the only problem I can think of would be if the black v would "trick" you if you're not using and mistakenly write in the wrong name. chandl · 20:45, 14 March 2009 (UTC) ::::::Argh, I meant the 'd' link. If the 'v' link comes up red, that should be ringing big alarm bells... :D [[User:Happy-melon|'Happy']]‑[[User talk:Happy-melon|'melon']] 21:28, 14 March 2009 (UTC) :::::::Hehe, we'll personally I think I'd want a link if a 'd' is gonna be shown, red or blue, though that might be have to be done with #ifexist, rather no d than a d with no link on it imo. chandl · 21:54, 14 March 2009 (UTC) ::Smaller? I intended to make them bigger (from xx-small to 85%). That only shows how inconsistent pre-defined CSS values are handled. What is youtr browser? :Aargh... fixed the bullet sizes (linked to font-size). Please try to get it right in one edit. We should all give the "Go" before going live. Stay sharp, people! — Edokter • Talk • 00:12, 15 March 2009 (UTC) ::The big bullet's don't fit imo, am I correct in that the small bullets were how it was before? chandl · 00:30, 15 March 2009 (UTC) :::Partly. The original used big bullets, but slightly reduced in size (85%). In the sandbox, I replaced them with non-reduced bold mid-dots to compensate for the larger font. But those are too small with the original xx-small font that Happy-melon put back. — Edokter • Talk • 00:40, 15 March 2009 (UTC) ::::http://i41.tinypic.com/bhy9uv.png Isn't the middle one how the previous version was? That's at least how I remember it, and of those three, my favourite (the top is the current, the bottom is the first version of the new) chandl · 00:45, 15 March 2009 (UTC) ::::Or it seems to have been a bullet of 80% inside xx-small v • d compared to v • d, and personally I like the former of these two. For me it's just better proportioned between the bullet and the letters. chandl · 00:51, 15 March 2009 (UTC) :::::Your browser shows some big bullets... to me (IE6) the current code shows as the bottom one, which is just right IMO. The middle one is just too small. What is your browser? — Edokter • Talk • 01:07, 15 March 2009 (UTC) ::::::Firefox, now the image doesn't show how my '•' is shown, the middle one shows '·' is shown (which I firstly thought was the old one) chandl · 01:15, 15 March 2009 (UTC) :::::::My Firefox also shows as the bottom one, just as IE. — Edokter • Talk • 01:25, 15 March 2009 (UTC) ::::::::The bottom one in the picture is for me how this version look, while the top one is the current. "v • d • e" is how I would like it to look. chandl · 01:37, 15 March 2009 (UTC) ::::::::Now looking in IE, Opera, Chrome and Safari • and • doesn't look so much different, but in my Firefox the right one looks almost twice the size (forgot to mention, I don't use Arial, which I guess in the default font.) :S chandl · 01:41, 15 March 2009 (UTC) :(←)Ah, indeed. The default font is 'sans-serif', which usually defaults to Arial. We can't please everyone. This cahnge was about removing as much as unnecessary code as possible. — Edokter • Talk • 02:32, 15 March 2009 (UTC) ::What about adding , it doesn't add that much extra code and hopefully looks pretty much the same in Arial ••, left is with small, right without chandler ' 02:47, 15 March 2009 (UTC) :::Hardly visible on my end, and is just as unpredictable across browsers. — Edokter • Talk • 19:09, 15 March 2009 (UTC) ::::Well that's the idea, that in Arial it will look the same, but for users who use a non-default font it will make it look like it did before these changes. 'chandler ' 20:01, 15 March 2009 (UTC) :::::I mean the small middot is barely visible using the default font, nit that there is no difference. Even the bold middot barely shows up with xx-small. — Edokter • Talk • 22:28, 15 March 2009 (UTC) ::::::Yea I know but the old one was a •, so it wouldnt be the middot, 'chandler ' 22:59, 15 March 2009 (UTC) :I don't really know what's going on above, but did we have a conclusion? The big dots look awful... [[User:Happy-melon|'Happy]]‑[[User talk:Happy-melon|'melon']] 11:12, 27 March 2009 (UTC) Issue with See here; it involves the color of the view-talk-edit links produced by the template. – TM ' 01:14, 6 March 2009 (UTC) Move? With the navbar now able to take pages in any namespace, we can now merge and . I've currently done that by redirecting navbar here, but I wonder if it would be clearer to move this template to Template:Navbar and protect the redirect from Template:Tnavbar. Thoughts? [[User:Happy-melon|'Happy]]‑[[User talk:Happy-melon|'melon']] 11:15, 27 March 2009 (UTC) :Such a move would have my support, but what would you do with the current history and talkpage of ? 「ダイノガイ ？！」(Dinoguy1000) 02:04, 28 March 2009 (UTC) ::I'm in favor of the move with a history merge (or making the navbar history that of the existing tnavbar). --CapitalR (talk) 05:47, 28 March 2009 (UTC) :Not really needed in my view. The template name has propagated to virtually every other project. And who is going to repair the thousands of links? (Well, I guess a bot could...) — Edokter • Talk • 15:45, 28 March 2009 (UTC) ::What other projects are doing really shouldn't be controlling our own actions here, and I don't see why the links would need to be updated so urgently. Update the instances that are called from and company, and any others can be individually corrected by local editors over time. It's not like the name is going to be reused by a different template. 「ダイノガイ ？！」(Dinoguy1000) 17:38, 28 March 2009 (UTC) :::The links wouldn't need to be fixed because they would never be broken; with a protected redirect at Template:Tnavbar there would be no need for a systematic replacement. Simply changing the link in would tackle the vast majority of cases. Since the current version of doesn't contain any material from the old , I'd be inclined to simply delete the old history of that page; it's mostly me anyway :D. The talkpage can become an archive subpage. Just because it's not needed doesn't mean it shouldn't be done, Edokter; not every action has to be a solution to a problem. [[User:Happy-melon|'Happy']]‑[[User talk:Happy-melon|'melon']] 14:54, 2 April 2009 (UTC) ::::Well, I won't oppose it, I just think it's unnecessary. — Edokter • Talk • 21:07, 2 April 2009 (UTC) I did it, in the absence of any genuine dissent :D. Welcome to Template talk:Navbar! [[User:Happy-melon|'Happy']]‑[[User talk:Happy-melon|'melon']] 19:40, 19 April 2009 (UTC) :*looks around* Ooh, pretty new decor (not to mention, now the name makes sense *without* having to spend a couple seconds thinking about it)! =D 「ダイノガイ ？！」(Dinoguy1000) 19:38, 21 April 2009 (UTC) v d e links not displaying correctly I imported some pages with templates to another wiki, but the Navbar v,d,e links show up as Template:PAGENAME: World Heritage Sites in Peru|v instead of just "v" for example. The PAGENAME magic word works fine otherwise, just displays like this in Navbox Navbars. Any ideas how to fix this or what might be missing? —Preceding unsigned comment added by (talk) 19:51, 18 May 2009 (UTC) :Your wiki is not running a recent-enough version of MediaWiki to have the parser function; the wiki needs to be running r46662, or version 1.15, in order for this feature to work correctly. [[User:Happy-melon|'Happy']]‑[[User talk:Happy-melon|'melon']] 20:12, 18 May 2009 (UTC) Transclusion count? I'm getting tired of seeing this being changed to 3,000,000+ only to be reverted back to 800,000. Wikipedia:Database reports/Templates with the most transclusions (last updated June 22) explicitly shows Navbar as being transcluded onto almost 3.3 million pages, so why is it inaccurate? If it's because shows the much lower figure of 800,000, I'd like to point out that it was last updated on September 16, 2008. 「ダイノガイ 」 · Talk⇒Dinoguy1000 20:22, 30 June 2009 (UTC) :Would you like to revert Edokter's last edit? -- WOSlinker (talk) 20:29, 30 June 2009 (UTC) ::The template is transcluded 3.3 million times; that does not mean it is on 3.3 million pages. It is transcluded multiple times on one page. If there are five navboxes, navbar is transcluded 5 times. Saying the template is used on 3.3 million "pages" is just plain wrong; there are not even that many pages. What you want is a link count, not a transclusion count. — Edokter • Talk • 20:33, 30 June 2009 (UTC) :::Ok, I've left a message about that report on the Database_reports talk page. -- WOSlinker (talk) 20:51, 30 June 2009 (UTC) ::::My assumption was always that the reports only counted a given page a single time, even if the template in question was transcluded onto it multiple times (and MZMcBride's reply on WT:Database Reports seems to confirm that). And there most certainly are over 3 million pages ( shows 17.2 million pages, counting all namespaces); keep in mind that both and are widely transcluded outside the mainspace. 「ダイノガイ 」 · Talk⇒Dinoguy1000 20:55, 30 June 2009 (UTC) ::The report just counts the number of times each template has an entry in the templatelinks table, and shows the top thousand templates. Every time a page is saved, the templatelinks table is updated to include one entry for each template used on the page, however many times it's used. So if there are 3.3 million entries in the templatelinks table for this template, that means it is transcluded on 3.3 million distinct pages (not, as Dinoguy notes, 3.3 million articles, of which there aren't that many; but there are plenty of other pages in other namespaces). The templatelinks table is used for cache invalidation (knowing which pages have to be rerendered if the template is updated), not specifically for statistics like this. In the same way, the pagelinks table only contains one entry for each link, however many times the link is duplicated on the page. Pages do not appear more than once in just because there are several identical links on a page, nor pages included in a category twice if two category links are placed on the page, even if they have different sortkeys. [[User:Happy-melon|'Happy']]‑[[User talk:Happy-melon|'melon']] 21:17, 30 June 2009 (UTC) :::If the databse report indeed reports 3.3 million distinct pages, then the error is mine. — Edokter • Talk • 21:31, 30 June 2009 (UTC) Navbox section editing Hi, is it possible to Navbox templates by section as one can already do in most wiki articles? I think that it would be a useful feature for those who may only want to edit a particular group, column or subgroup without having to muddle through the entirety of the template's wikilinks. --Toussaint (talk) 05:07, 7 July 2009 (UTC) :Short answer: "no". Long answer: "no, because navboxes aren't broken up into divisions that can be recognised by the MediaWiki software". [[User:Happy-melon|'Happy']]‑[[User talk:Happy-melon|'melon']] 12:35, 7 July 2009 (UTC) ::Thanks for the reply. Have the developers considered instituting such divisions into navboxes, or is it possible to work such a feature into MediaWiki in the future? It might be a nice feature to include, given the current ubiquity and expanding size of Navboxes throughout the wiki.--Toussaint (talk) 07:00, 8 July 2009 (UTC) :::Just as with articles, if a navbox grows too large, it should be considered for splitting into smaller, more focused navboxes. Navboxes are meant to aid navigation, not to be an exhaustive list of articles on a given subject (if such a list results in a sea of blue; for this reason, navboxes of e.g. all senators from state x'' have generally been frowned upon, from what little I've seen). Also note that navboxes can be nested, so even after splitting, they can still all be used with a single template transclusion on articles, and it allows individual groups of links to be separately edited, as you're asking for. 「ダイノガイ 」 · Talk⇒Dinoguy1000 20:35, 8 July 2009 (UTC) Proposed navbox changes There is an ongoing discussion at Template talk:Navbox#Usability and Accessibility to make an assorted variety of usability/accessibility improvements to Navbox, some of which may require modifications to Navbar's behavior. Anyone who hasn't already been by is invited to offer their opinion there. 「ダイノガイ 」 · Talk⇒Dinoguy1000 17:51, 25 August 2009 (UTC) Show/Hide not working I have never been able to successfully get the navbox onto my wiki! I've tried so many times and so many different ways. If someone could check out my code on my Common.css, Common.js, Template:Navbox and Template:Tnavbar. (I am using the version that does not require Tidy.) Everything words other than the show/hide which is not visible. I'm wondering if this is a IE8 thing? My wiki can be found at artsiedesigns.net/wiki and an example navbox can be found under "Template:WWNavbox". HELP! PLEASE! :D Usakoi84 (talk) 15:03, 18 March 2010 (UTC) Help? I tried to convert Template:Public_finance from a wikitable into a but for some reason its Navbar is showing up as "v • [[|d]] • [:Template:Fullurl:Template:e]" instead of the expected "v • d • e" links, and I can't figure out why, so please help fix it. (talk) 22:11, 29 April 2010 (UTC) :fixed. All it needed was a name param. http://en.wikipedia.org/w/index.php?title=Template:Public_finance&diff=359144555&oldid=359143409 -- WOSlinker (talk) 22:15, 29 April 2010 (UTC) ::Thanks! (talk) 22:15, 29 April 2010 (UTC) Navbar in a wikitable In this template there is a Wikitable used as a Navbox. I cannot get the great v-d-e Navbar on the right place (i.e. top left, no newline). Could someone direct me to some ''documentation on this? I'd say, about using the Navbar outside of a Navbox. Also, someone could solve the problem at the template, and I'll take a look to learn. -DePiep (talk) 20:03, 12 May 2010 (UTC) -minor edit -~ :I made the changes on the template so you can see how it works. I just wrapped the navbar in a left floating div of width 6em and it seems to work. That's how Navbox works under the hood. I also added class="navbox collapsible" to your template to make the style more consistent with other navboxes. Let me know if you still have questions and I can try to help out. --CapitalR (talk) 21:00, 12 May 2010 (UTC) ::Great! Looks real Wiki now (btw, it is not "my" navbox, I inherited it ;-)). "Under the hood" is too deep for me, but I'll keep a link to in mind. Must be CSS. Thx, -DePiep (talk) 21:11, 12 May 2010 (UTC) Someone to top it up? I've been enjoying producing the content, but layout is a different game. Could someone make an nice edit? The tabletop could be better in: * v-d-e-box; Hide/Show; maybe fixed width; and layout in borders and even colors. ** Quite bad: the sort-marks are not with the columns, but with the colspan="2"-marquee-row. -DePiep (talk) 22:40, 19 May 2010 (UTC) Added -DePiep (talk) 09:35, 20 May 2010 (UTC) Edit request from Doulce, 21 May 2010 Hello, when you search my name it appears and states that I resigned in disgrace. I need that removed, I did not resign in disgrace and that statement has recently cost me a new job. Doulce (talk) 01:23, 21 May 2010 (UTC) Doulce (talk) 01:23, 21 May 2010 (UTC) :I believe this matter was resolved here: Wikipedia:Help_desk#Negative_title. Removing protected edit request as it is misplaced. --CapitalR (talk) 01:33, 21 May 2010 (UTC) Font size (again) :See also: MediaWiki talk:Common.css#Navbar font size The v-d-e links are too small; they push the limit on how small the letters can be. They are inelligable and require a steady hand to click on. This has been a pet peeve of mine for a long time. It doesn't help that the fontsize is defined inline, and then even further reduced when used in a template such as . I have been experimenting in the sandbox and need input. My proposal is to use a font-size of 88% (same size as used in navbox) and ensuring it stays that way by putting the following code in common.css, and removing the hardcoded font sizes from the template: .navbar { /* Navbox template links */ font-size: 88%; /* Default font-size */ font-weight: normal; } .navbox .navbar { font-size: 100%; /* When nested within navbox */ } At the same time, I changed the bullets to middots and condensed the whole by using half-spaces. I also changed all the divs to spans, as I cannot see the advantage of using divs and have not seen any breakage where spans are used. This means we can eliminate nodiv=1 as well. I have already put the code in Common.css; since the font size is hardcoded in the template, this code has no effect on the live template, but does work for the sandbox version. The effects are viewable in Template:Navbox/testcases. This should give us enough time to discuss, and possibly make it live in 30 days. — Edokter • Talk • 17:21, 7 December 2010 (UTC) :No comments for a whole months... I guess there are no objections. The new code is now live. Please report any issues here (although I do not expect any after a month of very extensive testing). — Edokter • Talk — 00:22, 7 January 2011 (UTC) WP:TRAN version? Is there a WP:TRAN-compatible version of this template? The WP:TRAN version of Template:Navbox uses it, but there is no version of this template there. kelvSYC (talk) 07:02, 9 December 2010 (UTC) :Yes, it's at Wikipedia:WikiProject Transwiki/Template:Navbar. It needs updating though. — Edokter • Talk • 11:40, 9 December 2010 (UTC) Opera issue In Opera 11.00 (Vector skin), transclusions of this template show the rectangle denoting "unrecognised character" instead of the   entity. For example, which uses : Cutting out the irrelevancies, this comes down to :v · d · e which shows as :v · d · e It does the same if is omitted. Is it an Opera bug causing the non-recognition of  ? It looks fine in Firefox 3.6, Google Chrome and Internet Explorer 7. --Redrose64 (talk) 17:41, 19 January 2011 (UTC) :I would say that is an Opera bug.   is a pretty standard HTML entity, defined in the HTML 4.0 standard, which is 12 years old. Do you see it in normal navboxes as well? — Edokter • Talk — 18:29, 19 January 2011 (UTC) ::Yes, in such as which uses and in turn ( ) --Redrose64 (talk) 19:41, 19 January 2011 (UTC) :::Does opera use any non-standard sans-serif font on your machine (which I asume in Windows)? And what happens in stations Greater Manchester|useskin=monobook}} another skin? — Edokter • Talk — 20:13, 19 January 2011 (UTC) ::::Same font that Firefox 3.6 uses. Windows XP. The problem is skin-independent (tried stations Greater Manchester|useskin=chick}} Chick, stations Greater Manchester|useskin=classic}} Classic, Monobook, stations Greater Manchester|useskin=nostalgia}} Nostalgia, stations Greater Manchester|useskin=simple}} Simple, stations Greater Manchester|useskin=vector}} Vector). --Redrose64 (talk) 20:56, 19 January 2011 (UTC) :(←) It seems Opera has more problems with HTML entities, but   and ohter spacer entites seem to be prone to bugs. I'll try to find another method to space the middots. — Edokter • Talk — 01:48, 20 January 2011 (UTC) ::I got rid of the thinsp. How does it look in Opera? — Edokter • Talk — 02:30, 20 January 2011 (UTC) :::Looks fine in Opera, where the appearance seems consistent with IE7 and Chrome. Curiously, Firefox shows those spaces very slightly thinner than the others. Don't worry about that though. --Redrose64 (talk) 12:31, 20 January 2011 (UTC) fontcolor Greetings, this template forces a font color by use of the fontcolor param I believe, and is causing problems with dark backgrounds and layouts and limits use of color coding in lists. If this could please be addressed and set back for default font coloring or removed outright, it would alleviate the issues. Thanks Srobak (talk) 15:38, 6 May 2011 (UTC) :Fontcolor had been deprecated long ago. Use the fontstyle option instead (for example: fontstyle=color:green). — Edokter (talk) — 16:18, 6 May 2011 (UTC) ::Ok, that still doesn't fix the root problem. By it being set to black in the template, it is no longer neutral and takes precedence over other style and layout settings. It results in additional coding in order to circumvent. It should be restored to a neutral color setting. Srobak (talk) 17:02, 6 May 2011 (UTC) :::Black is neutral on any light backgrounds. No matter what color we set it to, it will always clash with some other color. That is why the fontstyle option is there. — Edokter (talk) — 17:19, 6 May 2011 (UTC) ::::There is always the option not to set it, vs. forcing it to black. Then it becomes neutral on any background and layout, as it is determined within those other templates, styles and skins. Forcing it to a color within the template itself makes it supersede style defaults. Srobak (talk) 17:42, 6 May 2011 (UTC) :::::What are you actually trying to do? I don't see you having done any template edits. (talk) 17:54, 6 May 2011 (UTC) :::::The template does not set the font color to black. It is inherited from the site's global CSS. Without styling, the brackets stay black, or inherit the parent template's font color, and the links get the default link colors. — Edokter (talk) — 18:23, 6 May 2011 (UTC) ::::::As an example, if a user has their default browser background set to a dark color, or uses something like the WP:VECTOR appearance skin and views a list or something which uses the navbar template (such as http://en.wikipedia.org/wiki/Wimax#Comparison ), in which the content font is forced to black - they cannot see the content without highlighting it or altering the layout, despite the default font color propagating through the rest of the article, and being visible regardless of background color. Srobak (talk) 18:32, 6 May 2011 (UTC) ::::::Thanks. Got it now. (talk) 18:39, 6 May 2011 (UTC) style Following on from the above, we appear to have two parameters which can be used to force styling. These are and , which are applied in different ways - the essential differences are (i) is applied once, enclosing the whole template, whereas is applied at lower level, enclosing each individual item in the template; and (ii) where they conflict, has precedence over . In the absence of both, the default styling for the part inside the brackets (the three view/talk/edit links) is style="white-space:nowrap;word-spacing:-.12em;", and the default styling for the whole template is class="noprint plainlinks navbar". Why are both and necessary? --Redrose64 (talk) 14:07, 7 May 2011 (UTC) :Fontstyle is necessary to force the styling of links, which would otherwise be overridden by the default linkstyle. The style parameter covers the entire template for styling such as background and placement. The current setup provides the most flexibility. — Edokter (talk) — 14:14, 7 May 2011 (UTC) ::Try it and see. -- WOSlinker (talk) 14:22, 7 May 2011 (UTC) ::